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Abstract 

We describe recent work on designing an environ- 
ment. called Java PathExplorer, for monitoring the 
execution of Java programs. This environment fa- 
cilitates the testing of execution traces against high 
level specifications, including temporal logic formu- 
lae. In addition, it contains algorithms for detecting 
classical error patterns in concurrent programs, such 
as deadlocks and data races. An initial prototype of 
the tool has been applied to the executive module of 
the planetary Rover K9, developed at NASA Ames. 
In this paper we describe the background and mo- 
tivation for the development of this tool, including 
comments on how ff relates to formal methods tools 
as well as to traditional testing, and we then present 
the tool itself. 

1 Introduction 

Software is getting an increased importance in 
the development of space craft and rover technol- 
ogy within the space agencies. It is recognized 
that future space* crafts will become highly au- 
tonomous. taking decisions without communication 
from ground. Hence, the required software is be- 
coming more complex, incre;using the risk of mission 
failures. Testing of such systems therefore becomes 


crucial. Traditional testing techniques, however, are 
very ad hoc and do not allow for formal specification 
and verification or testing of the properties that a 
system needs to satisfy. 

The Automated Software Engineering group at 
NASA An; Re. at... Chat*. i.as to* th * la- ■ hi *e 

years worked on developing advanced verification 
and testing technology for space applications. Part 
of this work has consisted of performing case studies 
using formal methods, in particular model checking, 
to analyze space craft software [6]. Based on the 
experiences of these case studies, two tools have fur- 
thermore been developed, both supporting full state 
space exploration of Java programs using explicit 
state model checking techniques [7, 14]. These tech- 
niques allow for checking temporal logic properties 
on programs that have a few million states, but fail 
to apply on large programs. Abstraction is required 
in order to increase the applicability of such tech- 
niques. an often manual and labor-some process. 

We present a new runtime verification system. 
Java PathExplorer (JPaX). for monitoring of Java 
program execution traces. The general concept con- 
sists of extracting events from an executing program, 
and then analyzing the events via a remote observer 
process. The observer performs two kinds of ver- 
ification: Ituju: based nionitoruu) and error pattern 

analysis. 

Loyic based monitoring consists of checking exe- 
cution tract's against user-provided formal require- 
ment specifications, written in high level logics. 
Logics ar<‘ currently implemented m the specifica- 
r ion language Maude :lj. a high-performance system 
supporting both membership equal innul logic and 
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.1 flexible manner uu h .i> for example »emporal lev- 
ies. r < i^i r In r ;v ith ^hi ti t >[>* i vr.i< >u.il >emanfu > ( .ur- 
i'i ’ii f 1 v we '■itppurf future Mine and past f 1 1 im ■ linear 
temporal logic as [ ) r* ‘f [* * H r i* 1 logics. Hie implemen- 
tation < it both these logics cover les s than 1-50 lines, 
lionet 1 defining new Indies. for example domain spe- 
cific uties, should be verv feasible tor an advanced 
user. The current. version ot Maude can do up to 
.] million rewritings per second on SOOMhz proces- 
sors. and its compiled version is intended to support 
lo million rewritings per second. Hence Maude can 
be used as the monitoring engine that performs the 
conformance checks of events against specifications. 

ErTor pattern analysis consists of analyzing execu- 
tion events using various error detection algorithms 
that can identify error-prone programming practices. 
Examples are unhealthy locking disciplines that may 
lead to data races and deadlocks. For example, a 
deadlock potential can be discovered from a single 
trace, even if that particular trace has no deadlocks, 
if it can be observed that lock acquisitions do not 
follow a partial order. By not requiring the errors to 
actuallv occur in order to be detected, this is a way 
to obtain a high degree of coverage although onlv 
one cxerUu.oii irn j is ox> mimed. In 0 v*ieial, we t : \ 
to identify various concurrency error patterns. 

The idea of using temporal logic in program test- 
ing is not new, and has already been pursued in the 
commercial Temporal Rover tool (TR) [3], and in 

- MaC tool [10]. TR allows the user to specify 
poral formulae as comments in programs. The 
MaG tool is closer to w'hat w r e describe in this pa- 
per. except that its specification language is very 
limited compared to the Maude language. In ad- 
dition, we combine specification checking with error 
pattern analysis. In a tool like Visual Threads [4, 13], 
these runtime analysis algorithms have been hard- 
wired into the system and are therefore difficult to 
change or extend by .a user. 

Eventually the system should allow to monitor 
programs composed of subprograms written in dif- 
ferent programming languages including also C + 4- 
and C. The system described in this paper will focus 
on Java. A case study of 90,000 lines of C + 4- code 
for a rover controller has been carried out. leading to 
the detection of a deadlock with a minimal amount 
of effort. It is our main goal to make the system as 
general and generic as possible, allowing to handle 
multiple language systems, and allowing new verifi- 
cation rules to hr defined, even defining new spec- 
ification logics using Maude- This way we hope to 
make the system a basis for experiments rather than 
a fixed system. 


MTibes I he * » vet .ill - ireii i r ec r HO' 1 J r he O. 'tem. Section 
;5 describes I he imderivmg logic fnrm.ili>ms tor writ- 
ing requirement. Tpecjfirnt ions, while Section l de- 
scribes '< >nie >f tie* cn-or detection algorithms for de- 
bugging concurrent programs. Finnllv. Section "> con- 
tains conclusions and a description ot luture woik. 

2 System Architecture 

The architecture of JP\X is shown in Figure l. The 
input to JPaX consists of two entities tor rather 
pointers to these;: the Java program in byte-code 
format to be monitored {created using a standard 
Java compiler) and the specification script defining 
what kind of analysis is requested. The output is a 
(possibly empty ) set of warnings printed on a special 
screen. 


Specifications 



Figure 1: JPaX Architecture 

The specification script consists of an instrumen- 
tation script and a verification script. The instru- 
mentation script defines how the program should be 
instrumented w*hile the verification script defines ex- 
actly what kind of analysis should be performed, and 
if logic based monitoring is requested: what proper- 
ties should be verified. Currently, the scripts are 
written in Java, which calls Maude it needed. Thus, 
high level Java language constructs can be used to 
define the boolean predicates to be observed. Then 
the values of tho.se predicates are shipped to Maude 
for deeper logic-based analysis. 

.JPaX can be regarded as consisting of three 
main modules: an instrumentation module, an 

observer module, and an interconnection module 
that ties them together through the observed event 
stream. The instrumentation module performs a 
script-driven automated instrumentation of the pro- 
i; r am to be observed. The instrumented program. 







A Urn mil, w 1 1 1 -cut r-icvcrif "veins tn r In* interaction 
module. which Muf.lliT 1 C 1 USMll t.S I hem tn rll<'nhs(T' 
viiinm mndule. Lhe observer m.iv nm mi a different 

«i 1 1 1 1» i r i *r . jii winch ease tin* cvi’iit.i are transmit ted 
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tiit' general setup. 

The msrrurncnr.tr, inn is performed using the Jtrek 
Java bvte-code engineering tool [2] from Compaq. 
This r.nnl allows to read Java class tiles (byte-code 
tiles), traverse them as abstract syntax trees while 
examining their contents, and insert new code in a 
highlv flexible manner. The inserted code can access 
the contents of the method call-time stack at run- 
time. hence giving access to information needed in 
the analysis. The extracted information is transmit- 
ted in the events. The observer receives the events 
and dispatches these to a set of observer rules, each 
rule performing a particular analysis that has been 
requested. Observer rules can be written in Maude 
or in a traditional programming language such as 
Java, or even C if speed is crucial. Generally, the 
rule based design allows a user to easily define new 
runtime verification procedures. 

The only language specific part of the system is the 
instrumentation module. If one wants to set up the 
eiivuoiirnem. L. a ddferem language, :\iJu a* v.Tt, 
one will only have to replace this module. We tried 
this together with Rich Washington, a member of 
the Robotics group at NASA Ames, on a 90,000 line 
C — -r application, just activating the deadlock detec- 
tion rule, and located a deadlock. This work will be 
prefaced in a different publication. 

3 Logic based Monitoring 

As previously mentioned, JPaX currently allows two 
conceptually independent methodologies for runtime 
verification. One is specification based monitoring, 
which is the subject of this section, and the other 
is error pattern analysis presented in the next sec- 
tion. The main difference between the two is that 
the first counts upon an underlying logic in which 
the user can express any application dependent logi- 
cal requirements, while the second implements more 
or less standard programming language dependent 
algorithms that detect typical concurrency error po- 
tentials. In this way. we believe that JPaX offers a 
large, if not a full, spectrum of possibilities for run- 
time verification. 

In order to write a runtime requirement specifica- 
tion. the user should first choose an appropriate logic 
to express the intended properties. JPaX currently 
provides linear temporal logics, both future time and 


past time, as lunlfin logics, but "lie could relatively 
ensilv define new logics or enrich the existing ones. 
Notice that multiple logics can be used in parallel, so 
each propers can be expressed in its most -»uitable 
language. Since the Maude implementations of the 
current logics are quire compact, we took the liberty 
to include them in the paper. 

3.1 The Maude Language 

Maude [1] is a intuiularized specification and verifi- 
cation system that efficiently implements rewriting 
logic. It is relatively widely accepted that rewait- 
ing logic acts like a universal logic, in the sense that 
other logics, or more precisely their syntax and op- 
erational semantics, can be implemented in rewrit- 
ing logic. Furthermore, Maude provides support for 
meta-programming, so complex logic dependent rea- 
soning strategies can be implemented as well; how- 
ever, we didn’t need the meta-level yet, but w*e ex- 
pect to need it soon, as JPaX will be extended. 
There is not enough space to present the Maude no- 
tation in more detail here, but we 11 introduce some 
of it ‘on the fly*’ as we give examples, such as the 
following one. 

3.1.1 Propositional Calculus 

The following module for propositional calculus, 
which is heavily used in JPaX, implements an ef- 
ficient procedure due to Hsiang [9] to decide validity 
of propositions: 

food PROP-CALC is pr FORMULA 
*•* Constructors *«* 

op : Formula Formula -> Formula [assoc comm] 

op _++_ : Formula Formula -> Formula [assoc comm] 
vars If Z : Formula 7ar As* : AtomStata* . 

«q trua A X - X . aq falsa A A * t*ls* 

«q falsa X * I aq X X * falsa 
aq X A X * X 

aq X A (T ♦♦ 2) - (X A Y) ++ (X A 2) 
mmm Derived oparators *** 

Formula Formula -> Formula [assoc] 

Formula -> Formula 
Formula Formula -> Formula 
Formula Formula -> Formula 
aq X \/ Y » (X A Y) +♦ X Y 
«q 1 X 3 trua ♦♦ X 

aq X -> Y * trua ♦♦ X *■+ (X A Y) - 
aq X <-> Y * trua ♦+ X Y 
Data structura k Semantics 
aq (X A Y) {As*} - X{As*> A Y(As-> 
aq (X ♦♦ Y)(As*} ■ X{As*> ♦♦ Y { As* } 
andf a 

The underscores stay for arguments. The mod- 
ule FORMULA which is “protected” (or imported) de- 
fines the infrastructure for all the user-defined logics. 
That includes some designated basic sorts {or types) 
such as Formula for syntactic formulae. FormulaDS for 
formula data structures needed when more informa- 
tion then the formula itself should be kept for the 


op _\/_ 
op «_ 
op _->_ 
<-> 



1 1 ( ' \ f r r. k 1 1 ^ 1 1 Kin i.'* m 'li'' 'Msi' ■ >1 [mm niiir 1 1 in mi* 
i i*fujn * i . 1 1 !i . A tomS t ate !< >r « tssign men! s * >1 boolean 
values o> .ifniiiic propositions and AtomSt.it** lor as- 
signments ,i.s above together with liii.d assignments, 
uv. those that an 1 fi >ili >w» ■« i by the end of Man* (our 
semantics for the i*ml of the execution trace is that of 
a continuous process that doesn t chan^' tin* state). 
Uho usit is tree to extend these types anil/ or pro- 
vide appropriate implementations for thorn as in the 
modulo above. Perhaps the most important oper- 
ation provided by the module FORMULA is an oper- 
ation _ { : FormulaDS AtomState -> FormulaDS which 
updates the formula data structure when an (ab- 
stract) stare change occurs during the execution of 
the program. Notice that this update operation acts 
like a morphism for propositional calculus, so it ba- 
sically evaluates the propositions in the new state. 

3.2 Linear Temporal Logics 

Linear temporal logics (LTL) are widely accepted 
as reasonably good formalisms to express require- 
ments of reactive systems. However, there is a tricky 
aspect of specification based monitoring which dis- 
tinguishes it from other formal methods tech ni ones, 
suen us model checking and tueoieui proving: the 
end of trace. Sooner or later, the monitored pro- 
gram will be stopped and so its execution trace. At 
that moment, the observer needs to take a decision 
regarding the validity of the checked properties. Let 
us consider for example the formula □ (p -+ o q)- If 
Mach p was followed by at least one q during the mon- 
itored execution, then, at some extent one could say 
that the formula was satisfied; but one should be 
aware that this is not a definite answer because the 
formula could have been very well violated in the fu- 
ture if the program hadn't been stopped. If p was 
true and it was not followed by a q , then one could 
say that the formula was violated, but it may have 
been very well satisfied if the program had been let to 
continue its execution. However, there are LTL prop- 
erties that give the user absolute confidence during 
the monitoring. For example, a violation of a safety 
property reflects a clear misbehavior of the moni- 
tored program. 

The lesson that we learned from experiments with 
LTL monitoring is twofold. On the one hand, we 
learned that, unlike in model checking or theorem 
proving. LTL formulae and especially their violation 
or satisfaction must be regarded with provisions dur- 
ing monitoring. On the other hand, we developed a 
belief that LTL may not be the most appropriate for- 
malism for logic based monitoring; other more spe- 
cific logics, such as real time LTL. interval logics, or 


even uud isc< > vf t< m i iiiirv could be < T greater interest 
r han pmi’ Lib In the next -aibsertious we briefly 
describe out ample implementations ot tunin' time 
and past, time L 1 L m Maude. 

3.2.1 Future Time LTL 

Future time LTL can be implemented more e;isilv 
than we initially thought on top of propositional cal- 
culus. It, basicallv jieeds only 5 rules, a pair for each 
operator: 

food FT - L Tl is «x PROP-CALC 
••• Syntax **• 

ops ([]_) (<>_) (o_) : Foraula -> Formula 

op Formula Formula -> Formula 

••• Data structure k Semantics 

7 axs X Y : Formula var As : AtomState 

eq ([] X) {As } « < [] X) A X<As> - 

eq ([] XHAs • } - X<As *> 

eq (<> X) {As > * «> X) \/ X{As> . 

eq (<> XHAs *> * X{As •> 

eq (o XHAs > * X . 

eq (o X){As *} * X{As 

eq (X 0 YHAs > - Y{As> \/ (X{As> /\ (X U T» . 
eq (X U Y) {As *> * Y{As •> . 
endfm 

Each pair of rules says how a formula transforms 
during the execution of the program. More precisely, 
they implement me following sunpie equivalences: 

st\=? iff t [= 
s [= y iff r{s*} = true ' 

where st is a trace formed by a state s followed by 
a nonempty trace t. while s can also be viewed as 
the trace consisting of s followed by the end of trace. 
A proof of correctness of this algorithm is given in 
[8], Despite its overall exponential complexity, this 
algorithm tends to be quite acceptable in practical 
situations. We couldn't notice any sensible difference 
in global concrete experiments with JPaX between 
this simple S rule algorithm and an automata based 
one that implements in 1,400 of .Java code a Buchi 
automata algorithm adapted to finite trace LTL (see 
Subsection 3.3). 

3.2.2 Past Time LTL 

Past time LTL is useful for especially safety prop- 
erties. These properties are very suitable for logic 
based monitoring because once they fail we know for 
sure that the program is not correct. The imple- 
mentation of past time LFL is a bit more tedious. 
It is also built on top of propositional calculus, by 
adding the usual two past time operators, *- for pre- 
vious and -S- for since, and then appropriate data 
structures am l semantics: 



rmo.t ;»r ltd h .•< ’bop-calc 

••• ) /nr. ix 

>p FormiCi -» rormul.i 

>p i . FormuLi Formula -* Frirmul.i 
• D.iti it.rucr.uri k iiainant; i <; 3 
ip pt.Lr. L roruult -> Fnrmui iDS 
jp itom Atom 3ooL -> FormulaDS 
ops priv ForrauIiDS 3ooL -> Formui.iOS 

ops irui tor sine* FormuiaDS FormulaDS 3ool -> FormulaDS 
/ars X f Formula vars 0 Or Dy D’ Dr' Dy ’ FormulaDS 
/ar 3 Bool tar A Atom /ar As AtomStats 
aq ptLt 1 < true ) { As > * tru« **q ptLt 1 ( falsa J {As > * false 
*q ptLtl(A){As> * atom ( A , (A{As> »■ true)) . 
eq ptLtK" X){As> » false 
ceq ptLtlfX S Y){As> * since(Dr, Dy, [Dy]) 

if Dr :* ptltl(X){As> /\ Dy » ptLt L ( Y) {As > 
ceq ptLtl(X /\ Y){As> a and(Di, Dy, [Dr] and [Dy]) 
if Dr ’ ptLtl (X) {As> /\ Dy * ptLtl (Y) (As } 
ceq ptLtKX ♦♦ Y){As> 3 xor(Dr. Dy , [Dr] ror [Dy]) 
if Dr = ptLtl (X) (As > /\ Dy .* ptLtl ( Y> {As > 
eq [stoat A , 3) ] * 3 
eq [prev(D , B) ] * 9 
eq [since(Dr ,Dy ,3) J * B 

eq [and(Dr ,Dy . B) ] * B eq [ror (Dr , Dy , 3) ] » B 
eq atoa(A ,B) {As} * atom(A, (A{As> *■ true)) . 
eq prev(D.B) {Ae> » prev (D{A§> . [D] ) . 
ceq since (Dx , Dy , B) {As} * since(Dr * ,Dy ‘ , [Dy ’] or B and [Dr]) 
if Dx’ :■ Dx{As> /\ Dy * : * Dy(Ae> 
ceq and(Dx ,Dy , B) {As} * and(Dx ’ ,Dy * , [Dx ' ] and [Dy’]) 
if Dx’ :■ Dr{As} /\ Dy' :* Dy{As} 
ceq xor(Dx ,Dy , B) {As} * ror (Dx ’ ,Dy ' , [Dx * ] xor [Dy’J) 
if Dx’ :* Dx{As} /\ Dy ’ :* Dy{Aa> . 
eq »ton(A , B) {As •} * true . 
eq prev (D , B) {As «} * true . 
eq s ince (Dx , Dy , B) { As *} * true . 
eq and(Dx ,Dy ,8){As *> * true 
eq xor (Dx , Dy , B) {As *} * true 

The operation ptLTL initializes/creates the data 
structure associated to a past time LTL formula, the 
operation [ J reads the current truth value of a for- 
mula, while the operator _{.} updates a formula data 
structure. 

3.3 Observer Generation 

As one naturally expects, monitoring via event ex- 
traction can significantly slow down the normal ex- 
ecution of the monitored program. In particular, 
the two event buffers of JPaX (one from the instru- 
mented program to the observer and the other from 
the observer to MJrude) sometimes slow down the 
original program by an order of magnitude. We are 
still investigating the real reasons for this, but at this 
stage we believe that a significant factor comes from 
the buffer communication between the observer im- 
plemented in Java and the logic engine implemented 
in Maude. Therefore, it may be desirable to device 
Java implementations that directly check formulae 
against execution traces, at least for those logics that 
turn out to be heavily used. 

Since JPaX only uses linear temporal logics, we 
concentrated only on future time and past time LTL 
so far In [L2j we showed how one could generate a 
dynamic-prograttiming b;used algorithm from any fu- 
ture time LTL formula, showing that it runs in time 


ihfnti i, where n is rhr a/e < »f * I n ■ r race and rn is 
r he a/e of rhr formula I n tor f unar ri v, that algo- 
rithm visits rite execution tract 1 backwards, meaning 
dial, a formula can be tested utilv after the program 
is stopped and all its execution trace stored. Fortu- 
uateiv. the same idea applied on past time LTL yields 
bv diiaiizatiun a forwards algorithm which runs in 
the same time: it is hard to believe that one can test 
p;ust time LTL formulae on finite traces faster. 

Taking into aetpunt the continuously decreasing 
price of storage, the backwards algorithm for future 
time LTL [ 12] is acceptable even beyond the proto- 
typing stage of the tool. Our colleague Dimitra Gi- 
annakopoulou took the challenge and implemented 
in about 1.400 lines of Java code a modified version 
of a Buchi automata algorithm that takes into ac- 
count the particularities of finite trace LTL; the de- 
tails of her implementation will appear elsew'here. It 
seems that finite trace LTL is a significantly simpler 
and more computable logic than the standard infinite 
trace LTL. In particular, we were able to show' the 
existence and then generate a minimal standard au- 
tomaton from any formula, automaton that accepts 
exactly those finite traces that satisfy the formula; 
this construction will also appear elsewhere. 

ju. main Concern at tlno stage i. in\ * ..:ti&aie 

more suitable logics for monitoring than future time 
LTL rather than generating efficient implementa- 
tions for formula checkers. The flexibility and ease 
in developing and/or modifying logics in rewriting 
logic, as well as its expressivity, efficiency and sup- 
port for meta-programming, make Maude a perfect 
choice as a logic engine to validate user defined re- 
quirements at this early stage of JPaX. 

4 Error Pattern Analysis 

Error pattern analysis is conceptually based on an- 
alyzing an execution trace using various algorithms 
that are able to detect error potentials even though 
errors do not explicitly occur in the examined exe- 
cution trace. The goal is to extract as much infor- 
mation as possible from a single execution trace to 
be able to suggest problems in other execution traces 
that have not been explored. Two examples of such 
algorithms focusing on concurrency errors have been 
implemented in .JPaX: a data ran 1 analysis algo- 
rithm and a deadlock analysis algorithm. Previously, 
both algorithms have been implemented in the Vi- 
sual Threads tool [ lj to work for ( and ( - — Also, 
in recent work we implemented the data race* algo- 
rithm and a variant <>t the deadlock algorithm in the 
Java PathFinder tool :aj to work lor Java by mod- 



;t\ nr.; i hr l.toi it'tu.ii \I.u litre* described III ! llj. 
( ) 1 1 r ' < mhi i iitf i' > r i iirp* is ui make these algorithms 
A*uk Inc l,i': a. rung bvf* '-ft u Ir instrumentation: to 
integrate rlirin vtrh logic based momtnrm^; and to 
make it possible for in advanced user to program 
new error pattern analysis rules m a flexible manner. 

Error patrrrn analysis algorithms typically do not 
guarantee mat errors are found since they, after all. 
work on a single arbitrary trace. They also may 
vield false positives in the sense that analysis results 
indicate warnings rather than hard error messages. 
What is attractive about such algorithms is, however, 
that thev scale very well, and that they often seem 
r.o catch the problems they are designed to catch. 
That is. the randomness in the choice of run does 
not seem to imply a similar randomness in the anal- 
ysis results. In the following we will shortly describe 
the data race and deadlock detection algorithms. 

4.1 Data Race Analysis 

This section describes the Eraser algorithm as pre- 
sented in ,T3], and how it has been implemented in 
JPaX to work on Java programs. A data race oc- 
curs when two concurrent threads access a shared 
v v : ib. md \vh> a at c ast oim a-. cess is t i an ! 
the threads use no explicit mechanism to prevent the 
accesses from being simultaneous. The Eraser algo- 
rithm detects data races in a program by studying 
a single run of the program, and from this trying to 
conclude whether any other runs with data races are 
possible. We will illustrate the data race analysis 
with the following example. 

1. class Valu«{ 

2 . pr ivat* int x * 1 ; 

3 . 

4. public synchromiad 7oid addCValua v){x * x * T.getO;} 

5. 

6. public int g*t(){r*turn x;> 

7 . > 

3 

9. class Task «xt«nds t Thr«ad{ 

10. Valua 7l; Valua tr2;’ 

11 . 

12. public Task(Valua vl.Valua /2){ 

L3 this 7l * 7 L , this. v2 * 72, 

L4 this start ( ) . 

L5 > 

L6 

17 public 70 i d run(){vL add(v2);} 

13 > 

19 

20. class *ain{ 

21 public static void .uain(Str ing[] args){ 

22 Valua vl * n«v ValuaO: Valua v2 * naw ValuaO ; 

23 naw Task (•/! , v2) ; naw Task(v2,vl); 

24 > 

25 > 

Tim Value class defines an integer variable x, a 
synchronized method add for updating the variable 
f adding the contents of another Value variable), and 


.in im,v k in tiinm/ni method get b>r reading tin* vari- 
able |'|ie Task rki.ss i>. a thread Hass. instances of 
which can he Parted with the start method ro rx- 
(>i urr their run method. I wn mch tasks are started 
in rhe mam program on two instances of the Value 
class When running JPaX with tin* Eraser option 
switched on. a data race potential is found, report- 
ing that the variable x in tdass Value is accessed 
unprotected bv the two Task threads in lines 4 and 6 
respect! velv. The problem detected is that one Task 
thread can call the add method on an object, say u i, 
with <i parameter Value object t’j, and this method 
in turn calls the unsynchronized get: method on t/o. 
The other thread can simultaneously make the dual 
operation, hence, call the add method on c>. Hence 
the x in may be accessed simultaneously by the 
two threads. In fact two data race warnings are emit- 
ted since the same situation is possible with tq and 
vo interchanged. 

One could argue that all methods should be syn- 
chronized such that data races can be detected us- 
ing simple type checking. However it is often seen 
that Java programmers avoid defining all methods as 
synchronized in order to optimize the program (syn- 
chronization slows down an application somewhat). 
Fur. hri :tu vm : y:.ah.ouLu*' m a ebe; bf 

achieved by executing synchronized statements such 
as: 

synchroniz«d(7l) { 

7 1 . add (72) 

> 

In this case it becomes impossible to detect data race 
potentials syntactically. This is the situation in lan- 
guages such as C and C-*-+ using Pthreads [II]. 

The basic algorithm works as follows. Two data 
structures are maintained in the observer: a thread 
map keeps track of which locks are owned by any 
thread at any point in time. The second data struc- 
ture, a variable map , associates with each (shared) 
variable in the program at any point in time the 
biggest set of locks that has been commonly owned 
by all accessing threads in the past. If this set be- 
comes empty a data race potential exists. That is, 
when a field ts accessed for the first time, the locks 
owned bv the accessing thread at that time are stored 
in this set.. Subsequent accesses by other threads 
causes the set to be reduced to its intersection with 
the locks owned by those threads. An extra state ma- 
chine is introduced fur each field to keep track of how 
rnariv threads have accessed tin* variable and how 
This is used to reduce false positives in the case for 
example fields are initialized by a single thread with- 
out locks - which is safe) or several threads just read 
a variable after it has been initialized f which is also 
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Aim m^t. ' Ih* i * ', * * r 1 1.. - ' Miat * i r* * important La he 
- 1, if , i race rinalvsis are muillfor lockings and releases; 
.■ltlier resulting front exerurmg lava s iynchroruzed 
statements nr from * mIIiii^/ returning from synchro- 
nized methods. Furt hermore, alt accesses t<> Hold 
variables and class variables an* analyzed. 

Deadlock Detection 

A classical deadlock situation can occur where two 
threads £ [ and t-> share two locks v\ and t,* 2 . arid they 
take the locks in different order The deadlock will 
arise if takes tj[ and £-* immediately after takes \: 2 . 
Now 1 1 cannot get v 2 and t 2 cannot get i\. Using 
the previous example, we can create such a situation 
if we wrongly try to repair the data race by defining 
the get method in line 6 as synchronized: 

6. public synchronized int j«t(){r*tum t;} 

Now the x variable can no longer be accessed simulta- 
neously from two threads, and the data race module 
will no longer give a warning. However, when run- 
ning JPaX on the modified program, a lock order 
problem not present before is found and a warning 
states that two uoject instances of u»e Value c.aso are 
taken in a different order by the two Task threads, 
and it indicates the line numbers where the threads 
may potentially deadlock, hence v/here the access to 
the second lock may fail: line 4 where the call of the 
get method from the add method will lock the sec- 
ond object. Note that this deadlock does not need 
to occur in the execution in order for this warning 
to be issued. In fact, any execution of this example 
program will cause a warning to be issued. 

The algorithm works as follows. Two data struc- 
tures are maintained in the observer: as in the data 
race algorithm a thread map keeps track of which 
locks are owned by any thread at any point in time. 
The second data structure, a lock graph , maintains 
an accumulating graph of all the locks taken by 
threads during an execution, recording locking or- 
ders as edges. That is, an edge is introduced from a 
lock u\ to a lock u 2 in case a thread owns u x while 
taking u 2 . If this graph ever becomes cyclic it re- 
flects a deadlock potential. Note that this algorithm 
can catch deadlock potentials between many threads 
its illustrated for example by the classical dining 
philosopher's example, independent of the number of 
philosophers. The events that are important for the 
data race analysis are monitor lockings and releases; 
cither resulting from executing lava s synchronized 
statements or from calling/ returning from synchro- 
nized methods. 


O 

\ brief -tescripf u *ii ■»!' MAX a runtime \<*nti< .itmii 
cjivimumeiir nup'titlv under • wperimenrarion ami 
development. .v;ie presented. Mntivaiuon and inte- 
gration in rfii * i overall NASA Arnes auromated soft- 
ware engineering effort was highlighted, emphasizing 
that our mam goal was to smoothie combine test- 
ing and formal methods, while avoiding some of the 
pitfalls from ad hoc testing and the complexity of 
full-blown theorem proving and model checking. A 
general system architecture of JP.vX was depicted, 
followed bv more detailed explanations of its com- 
ponents. especially logic nosed monitoring and error 
pattern analysis. 

In future work on logic based monitoring, we will 
experiment with new' logics in Maude more appro- 
priate to monitoring than LTL, such as interval and 
real time logics and UML notations. The latter al- 
lows to check original designs (via state charts and/ or 
sequence diagrams) against real execution traces. 
A longer term agenda is oriented tow'ard fast imple- 
mentations of designated logics in more conventional 
programming languages than Maude, thus improving 
the overall speed of the monitoring process. Future 
v, n*]; or c. *'o . <tf: T m mcVs w ’1 zv\ to develoi 

new algorithms for detecting other kinds of concur- 
rency errors than data races and deadlocks, and of 
course to try to improve existing algorithms. 

We will also study completely new- functionalities 
of the system, such as guided execution via code in- 
strumentation to explore more of the possible inter- 
leavings of a non-deterministic concurrent program 
during testing: and guidance of the program dur- 
ing operation once a requirement specification has 
been violated. Dynamic programming visualization 
is also a future subject, where we regard a visualiza- 
tion package as just another rule in the observer. 

A more user friendly interface, both graphical and 
functional, wall be provided, in addition to an im- 
proved modularization of the whole system such that 
to easily adapt it to various programming languages 
and various instrumenting methodologies. Of course, 
the tool will be evaluated on real case studies. 
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